Remarks 



I. Interference 

Applicants appreciate the Office Action acknowledgement that applicants 
requested an interference with U.S. Patent No. 6,453,360 ("the 360 patent") on June 19, 
2003. With this reply, applicants respond to each of the items in the Office Action, and 
again respectfully request that an interference with the '360 patent be declared. 

II. Oath or Declaration in Conformance with Application Title 

The Office Action states that the Oath or Declaration is defective, because it 
recites the title: "INTELLIGENT NETWORK INTERFACE DEVICE AND SYSTEM 
FOR ACCELERATED COMMUNICATION," whereas the title of the Specification 
filed in the application recites: "HIGH PERFORMANCE NETWORK INTERFACE". 

Applicants have amended the title to conform to the Declaration. 

III. Objection to the Specification 

The Office Action objects to the specification as failing to provide proper 
antecedent basis for the "computer readable storage medium" that is claimed. 
Applicants have amended the specification to conform to the claims. 

IV. 35 U.S.C. §112 

The Office Action rejects claims 25 and 42 under 35 U.S.C. §1 12, second 
paragraph, as allegedly being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. 

A. Claim 25 

Regarding claim 25, the Office Action states: 

Claim 25 recites, "The method of claim 24, further comprising: 
transferring said TCB from said host computer system to said 
communication device." However, it appears in claim 24 that the TCB is 
generated at the communication device. Therefore it is unclear how the 
TCB is transferred from the host computer system to the communication 
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device if such is generated at the communication device. Clarification or 
correction is respectfully requested. 

Applicants respectfully assert that claim 24 does not require the TCB to be 
generated at the communication device. Thus, claim 25 is not indefinite. 



B. Claim 42 

Regarding claim 25, the Office Action states: 

Claim 42 recites the limitation "said memory area contents" in the 
last line of the claim. There is insufficient antecedent basis for this 
limitation in the claim. 

Applicants have amended claim 42 to replace "said memory area contents" with 
"said data portions." Applicants respectfully assert that claim 42 is no longer indefinite. 



V. 35U.S.C. §101 

The Office Action rejects claims 13 and 53 under 35 U.S.C. §101 as allegedly 
being directed to non-statutory subject matter. In this regard, the Office Action states: 

Claim(s) 13 and 53 recite a "computer readable storage medium" 
which appears to cover both transitory and non-transitory embodiments. 
The United States Patent and Trademark Office (USPTO) is required to 
give claims their broadest reasonable interpretation consistent with the 
specification during proceedings before the USPTO. See In re Zletz, 893 
F.2d 31 9 (Fed. Cir. 1989) (during patent examination the pending claims 
must be interpreted as broadly as their terms reasonably allow). The 
broadest reasonable interpretation of a claim drawn to a medium as 
claimed typically covers forms of non-transitory tangible media and 
transitory propagating signals per se in view of the ordinary and 
customary meaning of the term, particularly when the specification is 
silent of an explicit definition. See MPEP 2111.01. When the broadest 
reasonable interpretation of a claim covers a signal per se, the claim must 
be rejected under 35 U.S.C. § 101 as covering non-statutory subject 
matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) 
(transitory embodiments are not directed to statutory subject matter) and 
Interim Examination Instructions for Evaluating Subject Matter Eligibility 
Under 35 U.S.C. 5 101, Aug. 24, 2009; p. 2. 

The Examiner suggests that the Applicant add the limitation "non- 
transitory" to the medium as recited in the claim(s) in order to properly 
render the claim(s) in statutory form in view of their broadest reasonable 
interpretation in light of the originally filed specification. The Examiner 
also suggests that the specification may be amended to include the 
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medium to be described as non-transitory in order to avoid a potential 
objection to the specification for a lack of antecedent basis of the claimed 
terminology. 

Applicants have added the recitation "non-transitory" to claims 13 and 53 as 
suggested, and respectfully assert that claims 13 and 53 are not directed to non-statutory 
subject matter. Applicants note that the definition of statutory subject matter is in flux 
and applicants reserve the right to reclaim any subject matter that may be surrendered by 
adding the recitation "non-transitory" to claims 13 and 53, should the interpretation of 
statutory subject matter change in the future. 

VI. 35U.S.C. §103 

Claims 1-12, 14-17, 20-31, 42-44, 46-53, 55-56 stand rejected under 35 U.S.C. 
103(a) as allegedly being unpatentable over U.S. Patent No. 6,172,980 to Flanders et al. 
("Flanders"). 

A. Claims 1,24 and 53 

Regarding claims 1, 24 and 53, the Office Action states: 

Regarding claims 1, 24, 53, Flanders disclosed a method of 
transferring a packet to a computer system, wherein the packet is received 
at a communication device from a network (Flanders, col. 1, lines 39-41, a 
network router receiving and routing packets), comprising: 

parsing a header portion of a first packet received at a 
communication device to determine if said first packet conforms to a pre- 
selected protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header 
Processor) determines the protocol being used for the received data unit"; 
See also col. 6, lines 50-51); 

generating a flow key to identify a first communication flow that 
includes said first packet (Flanders, col. 6, line 50 through col. 7, line 5, 
port information extracted from the received frame in order to classify 
packet according to flow ID, the information extracted from the packet 
used as a flow key to look the packet up); 

routing the packets to their destination (Flanders, col. 1, lines 50- 
55, Flanders disclosed the router making forwarding decisions to route the 
packet, see also Abstract, "identifying a data unit to be routed by a router) 

associating an operation code with said first packet, wherein said 
operation code indicates a status of said first packet (Flanders, col. 6, line 
65 through col. 7, line 15, in accordance with the received frame, a status 
word is set; see also, col. 4, lines 15-23). 

Flanders further disclosed forwarding the packets for receipt by a 
downstream network device (Flanders, col. 9, lines 40-43). 
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Flanders did not explicitly state transferring said first packet to the 
disclosed device system for processing in accordance with said pre- 
selected protocol. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the information from that packet. For example, using the very 
well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol 
process the TCP/IP packets, which are clearly routed through the Internet, 
via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination performing the proper 
protocol processing in order to obtain the predictable result of the 
destination device being able to successfully interpret that packet at the 
receiving end, thereby resulting in successful communication. 

Claim 24 includes a method with limitations that are substantially 
similar to the limitations of claim 1, and is therefore rejected under the 
same rationale. Claim 53 recites a computer readable storage medium 
storing instructions that perform the method of claim 1 . Therefore claims 
24, 53 are rejected under the same rationale. 

Applicants have amended claim 1 to recite, in part, "transferring a packet to a host 
computer system, wherein the packet is received at a communication device for the host 
computer system from a network." Flanders, on the other hand, teaches "a network 
bridge/router for identifying received data units which may require routing, for 
identifying a protocol associated with the received data unit, for determining whether the 
received data unit is in fact to be bridged or routed, and for carrying out appropriate data 
unit transfer operations, all in hardware." Column 1, lines 39-44. In other words, 
Flanders teaches forwarding packets by its communication device rather than processing 
packets at the host computer for the communication device. Similarly, claim 1 has also 
been amended to recite "generating a flow key to identify a first communication flow that 
includes said first packet, wherein said flow key includes an IP address and a TCP port of 
the host computer system." The invention of Flanders is directed to hardware that 
determines whether packets are bridged or routed, and does not disclose a communication 
flow of packets including "an IP address and a TCP port of the host computer system." 
Likewise, claim 1 has been amended to recite "transferring said first packet to the host 



Reply to First Office Action 
App.No: 10/601,237 



20 



computer system for processing in accordance with said pre-selected protocol." 
Applicants respectfully assert that Flanders similarly does not teach this recitation. 

Claim 1 has also been amended to recite "associating an operation code with said 
first packet, wherein said operation code indicates a status of said first packet, including 
whether said packet is to be transferred to the host computer system for processing in 
accordance with said pre-selected protocol." Applicants respectfully assert that this 
recitation is not obvious over the "network bridge/router" disclosed in Flanders. As 
noted above, Flanders does not teach "transferring said first packet to the host computer 
system for processing in accordance with said pre-selected protocol," and there is no 
suggestion in Flanders of "associating an operation code with said first packet, wherein 
said operation code indicates a status of said first packet, including whether said packet is 
to be transferred to the host computer system for processing in accordance with said pre- 
selected protocol." 

Claims 24 and 53 have been amended in a manner similar to claim 1 . For the 
foregoing reasons, applicants respectfully assert that claims 1, 24 and 53 are not obvious 
over Flanders. 

B. Claim 2 

Regarding claim 2, the Office Action states: 

Regarding claim 2, Flanders disclosed the limitations as described 
in claim 1, including wherein said parsing comprises: copying a header 
portion of said first packet into a header memory; and examining said 
header portion according to a series of parsing instructions; wherein said 
parsing instructions are configured to reflect a set of pre-selected 
communication protocols (col. 3, lines 45-65). 

Claim 2 has been amended to recite in part "wherein said header memory does not 
store a remainder of said first packet." Support for the amendment can be found, for 
example, in FIG. 17 and page 72, lines 6-19 of the specification. Applicants respectfully 
assert that the cited portion of Flanders does not teach "a header memory" as recited in 
claim 2, and does not teach "copying a header portion of said first packet into a header 
memory, wherein said header memory does not store a remainder of the first packet" as 
recited in amended claim 2, but instead teaches a "Buffer RAM 22 for storing received 
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frames" Column 3, lines 51-52. For at least this reason, applicants respectfully assert 
that claim 2 is not obvious over Flanders. 



C. Claim 3 

Regarding claim 3, the Office Action states: 

Regarding claim 3, Flanders disclosed the limitations as described 
in claim 2. Flanders did not explicitly wherein said parsing instructions are 
updateable. However, it would have been obvious to any programmer or 
designer at the time the invention was made that any instructions carried 
out by a machine are updateable, as any software or hardware could be 
updated in order to accommodate the desires of the programmer/designer. 

As noted above, applicants have amended claims 1 and 2 so that both are 
patentable over Flanders, and claim 3 depends from claim 2, which in turn depends from 
claim 1 . For at least this reason, applicants respectfully assert that claim 3 is not obvious 
over Flanders. 



D. Claim 4 

Regarding claim 4, the Office Action states: 

Regarding claim 3, Flanders disclosed the limitations as described 
in claim 2, including copying a value from a field in a header of said 
header portion (Flanders, col. 6, lines 50-56). 

As noted above, applicants have amended claims 1 and 2 so that both are 
patentable over Flanders, and claim 4 depends from claim 2, which in turn depends from 
claim 1 . For at least this reason, applicants respectfully assert that claim 4 is not obvious 
over Flanders. 



E. Claim 5 

Regarding claim 5, the Office Action states: 

Regarding claim 5, Flanders disclosed the limitations as described 
in claim 1, including wherein said parsing comprises: extracting an 
identifier of a source of said first packet from said header portion; and 
extracting an identifier of a destination of said first packet from said 
header portion (Flanders, col. 3, lines 55-60). 
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Claim 5 has been amended to recite in part "extracting an identifier of a 
destination of said first packet from said header portion, wherein said destination is an 
application running on the host computer system." Support for the amendment can be 
found, for example, in the specification on page 10, lines 22-28. As noted above, 
Flanders is directed to "a network bridge/router" and as such does not teach or suggest 
"extracting an identifier of a destination of said first packet from said header portion, 
wherein said destination is an application running on the host computer system." For at 
least this reason, applicants respectfully assert that claim 5 is not obvious over Flanders. 

F. Claim 6 

Regarding claim 6, the Office Action states: 

Regarding claim 6, Flanders disclosed the limitations as described 
in claim 5, including combining said source identifier and said destination 
identifier (Flanders, col. 3, lines 55-60). 

As noted above, applicants have amended claims 1 and 5 so that both are 
patentable over Flanders, and claim 6 depends from claim 5, which in turn depends from 
claim 1 . For at least this reason, applicants respectfully assert that claim 6 is not obvious 
over Flanders. 

G. Claim 7 

Regarding claim 7, the Office Action states: 

Regarding claim 7, Flanders disclosed the limitations as described 
in claim 1, including wherein said generating comprises retrieving an 
identifier of a communication connection from said header portion 
(Flanders, col. 6, lines 49-60). 

Claim 7 has been amended to recite in part "wherein said generating comprises 
retrieving an identifier of a communication connection for the host computer system from 
said header portion." Support for the amendment can be found, for example, in the 
specification on page 10, lines 22-28. As noted above, Flanders is directed to "a network 
bridge/router" and as such does not teach or suggest "retrieving an identifier of a 
communication connection for the host computer system." For at least this reason, 
applicants respectfully assert that claim 7 is not obvious over Flanders. 
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H. Claim 9 

Regarding claim 9, the Office Action states: 

Regarding claim 9, Flanders disclosed the limitations as described 
in claim 1, including storing said flow key in a flow database, wherein 
said flow database is configured to facilitate management of said first 
communication flow (Flanders, col. 6, lines 50-65, "Flow Filtering 
Table"). 

Claim 7 has been amended to recite in part "wherein said flow database is 
configured to facilitate TCP management of said first communication flow." Support for 
the amendment can be found, for example, in the specification on page 10, lines 1-18. As 
noted above, Flanders is directed to "a network bridge/router" and as such does not teach 
or suggest "TCP management of said first communication flow." Instead, the "flow 
Filtering Table 1 12 (FIG. 13)" is used merely to identify whether the flow is "flow 
controlled or best efforts," which is used for routing and bridging, not for TCP 
management. For at least this reason, applicants respectfully assert that claim 9 is not 
obvious over Flanders. 

I. Claim 10 

Regarding claim 10, the Office Action states: 

Regarding claim 10, Flanders disclosed the limitations as described 
in claim 9, including associating a flow number with said first packet, 
wherein said flow number comprises an index of said flow key within said 
flow database (Flanders, col. 6, lines 50-65, "Flow ID"). 

As noted above, claim 9 has been amended so that it is patentable over Flanders, 
and claim 10 depends from claim 9. For at least this reason, applicants respectfully assert 
that claim 10 is not obvious over Flanders. 

J. Claim 11 

Regarding claim 1 1, the Office Action states: 

Regarding claim 11, Flanders disclosed the limitations as described 
in claim 10, including storing said flow number in a flow memory 
(Flanders, col. 6, lines 50-65, "Flow ID" is stored in the table). 
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As noted above, claim 9 has been amended so that it is patentable over Flanders, 
and claim 1 1 depends from claim 10, which in turn depends from claim 9. For at least 
this reason, applicants respectfully assert that claim 1 1 is not obvious over Flanders. 

K. Claim 12 

Regarding claim 12, the Office Action states: 

Regarding claim 12, Flanders disclosed the limitations as described 
in claim 9, including updating an entry in said flow database associated 
with said flow key when a second packet in said first communication flow 
is received (Flanders, col. 6, line 65 through col. 7, line 15). 

As noted above, claim 9 has been amended so that it is patentable over Flanders, 
and claim 19 depends from claim 9. In addition, applicants do not understand how the 
cited portion of Flanders teaches "updating an entry in said flow database associated with 
said flow key when a second packet in said first communication flow is received." 
According to the Office Action's rejection of claim 9, the "Flow Filtering Table" is 
mapped to "said flow database." A "second packet in said first communication flow" 
would have the same IP addresses and UDP/TCP ports as the first packet, and so no 
"updating" would occur. For at least these reasons, applicants respectfully assert that 
claim 12 is not obvious over Flanders. 

L. Claim 14 

Regarding claim 14, the Office Action states: 

Regarding claim 14, Flanders disclosed the limitations as described 
in claim 1, including wherein said associating comprises: retrieving one or 
more header fields of said header portion; and analyzing said header fields 
to determine said status of said first packet (Flanders, col. 7, lines 1-15). 

Applicants note that claim 1 has been amended to recite in part "associating an 
operation code with said first packet, wherein said operation code indicates a status of 
said first packet, including whether said packet is to be transferred to the host computer 
system for processing in accordance with said pre-selected protocol." As noted above, 
Flanders is directed to a "network bridge/router," and so does not teach "analyzing said 
header fields to determine said status of said first packet," wherein the status includes 



Reply to First Office Action 
App. No: 10/601,237 



25 



"whether said packet is to be transferred to the host computer system for processing in 
accordance with said pre-selected protocol." For at least this reason, applicants 
respectfully assert that claim 14 is not obvious over Flanders. 

M. Claim 15 

Regarding claim 1 5, the Office Action states: 

Regarding claim 15, Flanders disclosed the limitations as described 
in claim 14, including wherein said analyzing comprises: determining 
whether said first packet includes a data portion; and if said first packet 
includes a data portion, determining whether said data portion exceeds a 
pre-determined size (Flanders, col. 4, lines 30-40). 

Applicants note that claim 15 depends from claim 14, which in turn depends from 
claim 1 . "Flanders, col. 4, lines 30-40" merely discloses that the "RHP 46 buffers up to 
the first 84 bytes of the incoming frame, or less for smaller frames, in the internal register 
files 101 for frame processing." This does not teach "analyzing said header fields to 
determine said status of said first packet" as recited in claim 14, and in particular does not 
teach "wherein said operation code indicates a status of said first packet, including 
whether said packet is to be transferred to the host computer system for processing in 
accordance with said pre-selected protocol" as recited in claim 1 . For at least this reason, 
applicants respectfully assert that claim 15 is not obvious over Flanders. 

M. Claim 16 

Regarding claim 1 6, the Office Action states: 

Regarding claim 16, Flanders disclosed the limitations as described 
in claim 14, including wherein said analyzing comprises determining 
whether said first packet was received out of order in said first 
communication flow (Flanders, Fig. 6, TCP which is enabled for out of 
order packets). 

Applicants respectfully assert that Flanders does not teach "wherein said 
analyzing comprises determining whether said first packet was received out of order in 
said first communication flow." Instead, Flanders states: "The RHP 46 determines 
whether the received frame is TCP, and if so, sets a TCP/IP Flag in the RHP 46 to RFP 
48 status word (FIG. 6)." Column 7, lines 11-14. Flanders further states that "FIG. 6 
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illustrates an RHP to RFP status word," and "The RFP 48 is responsible for making 
forwarding decisions based on received data unit-characterizing information supplied by 
the RHP 46 ... " Column 2, line 3 8 and column 8, lines 11-14, respectively. Once again, 
Flanders is directed to forwarding, rather than terminating TCP. For at least this reason, 
applicants respectfully assert that claim 16 is not obvious over Flanders. 

N. Claims 20-23. 25 and 26 

Claims 20-23, 25 and 26 are claims that are dependent from claim 1 and claims 
21-23, 25 and 26 are increasingly further removed from Flanders due to their dependency 
from earlier claims such as claim 20. As such, applicants respectfully assert that Flanders 
does not teach the limitations of those claims for reasons similar to that mentioned above 
with regard to claim 1 . For at least this reason, applicants respectfully assert that claims 
20-23, 25 and 26 are not obvious over Flanders. 

O. Claim 27 

Regarding claim 27, the Office Action states: 

Regarding claim 27, Flanders disclosed the limitations as described 
in claim 1, including alerting said host computer system to the arrival of 
said first packet (col. 9, lines 40-45). 

Applicants respectfully assert that Flanders does not teach "alerting said host 
computer system to the arrival of said first packet" in column 9, lines 40-45. Instead, that 
portion of Flanders states: "Outbound frames are forwarded from the TXSM FIFO 64 
over the respective output port 20 of the network interface module 14 for receipt by a 
downstream network device. The TXSM 62 receives frames from the THP 60 and is 
responsible for transmitting data units from the device 10 out of the respective output port 
20." Once again, Flanders is directed to forwarding, and so "alerting said host computer 
system to the arrival of said first packet" is not alerting "the host computer," but a 
different computer that the packet is forwarded to. For at least this reason, applicants 
respectfully assert that claim 27 is not obvious over Flanders. 
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P. Claim 29 



Regarding claim 29, the Office Action states: 

Regarding claim 29, Flanders disclosed the limitations as described 
in claim 1, including wherein said parsing includes determining, by 
hardware of the communication device, a protocol of the header (col. 3, 
lines 50-60). Flanders also clearly disclosed the teaching of multiple 
protocol support. 

The teachings of Flanders does not limit itself to any particular 
type of protocol. This would have motivated one of ordinary skill in the art 
to implement the teachings of Flanders with any protocol well known in 
the art. 

The session layer is a well known layer from the OSI model. 
Therefore it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to incorporate the session protocol within 
the teachings of Flanders since in order to make the teaching of Flanders 
scalable across well known protocols, thereby increasing its customer's 
desirability of use. 

Applicants respectfully disagree. As noted above, Flanders is directed to 
forwarding, and "determining. . . a session layer protocol of the header" would only slow 
the forwarding, with no discernable benefit, so it is unlikely that one of ordinary skill 
would have modified Flanders to arrive at the recitation of claim 29. For at least this 
reason, applicants respectfully assert that claim 29 is not obvious over Flanders. 



Q. Claim 30 

Regarding claim 30, the Office Action states: 

Regarding claim 30, Flanders disclosed the limitations as described 
in claim 1, including wherein said generating a flow key includes 
initializing a communication control block (CCB) during Transport 
Control Protocol (TCP) connection setup (col. 7, lines 10-15). 

Applicants respectfully assert that Flanders does not teach "wherein said 
generating a flow key includes initializing a communication control block (CCB) during 
Transport Control Protocol (TCP) connection setup." Instead, Flanders states: "The RHP 
46 determines whether the received frame is TCP, and if so, sets a TCP/IP Flag in the 
RHP 46 to RFP 48 status word (FIG. 6)." Column 7, lines 1 1-14. Flanders further states 
that "FIG. 6 illustrates an RHP to RFP status word," and "The RFP 48 is responsible for 
making forwarding decisions based on received data unit-characterizing information 
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supplied by the RHP 46..." Column 2, line 38 and column 8, lines 11-14, respectively. 
Once again, Flanders is directed to forwarding packets, rather than initializing a 
communication control block (CCB) during Transport Control Protocol (TCP) 
connection setup. For at least this reason, applicants respectfully assert that claim 30 is 
not obvious over Flanders. 

R. Claim 31 

Regarding claim 31, the Office Action states: 

Regarding claim 31, Flanders disclosed the limitations as described 
in claim 1, including wherein said communication device is a network 
interface (Fig. 1). 

Applicants respectfully assert that Flanders does not teach "wherein said 
communication device is a network interface" and the "communication device (is) for the 
host computer system," as recited in claim 1, from which claim 3 1 depends. Instead, 
Flanders states in column 9, lines 41-43: "Outbound frames are forwarded from the 
TXSM FIFO 64 over the respective output port 20 of the network interface module 14 for 
receipt by a downstream network device." For at least this reason, applicants respectfully 
assert that claim 31 is not obvious over Flanders. 



S. Claims 42 and 44 

Regarding claims 42 and 44, the Office Action states: 

Regarding claims 42 and 44, Claim 42 includes an apparatus with a 
memory and modules to perform the limitations that are substantially 
similar to claim 1 and claim 44 recites a computer system with limitations 
that are substantially to claims 1. Claims 42 and 44 further includes a 
"flow re-assembler configured to re-assemble a data portion of said first 
packet with a data portion of second packet in said communication flow 
and storing both packets in memory as well as a processor to process said 
packet. As shown in the rejection of claim 1, Flanders disclosed a router 
performing these limitations. 

Flanders did not explicitly state flow re-assembler configured to 
re-assemble a data portion of said first packet with a data portion of 
second packet in said communication flow and storing both packets in 
memory of the downstream network device. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
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clearly routes the packets belonging to a particular flow to a network 
device, that the network device must perform the proper protocol 
processing on the packets in order to properly interpret the information 
from that packet, thereby requiring storing of the packet data and 
combining the data to properly interpret the flow. For example, using the 
very well known TCP/IP protocol, in order for two computers to 
successfully communicate via TCP/IP (Flanders, Fig. 6), both computers 
must protocol process the TCP/IP packets, which are clearly routed 
through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packets to their destination to include that destination actually storing the 
packet data in order to perform the proper protocol processing in order to 
obtain the predictable result of the destination device being able to 
successfully interpret/batch that data from the packets at the receiving end, 
thereby resulting in successful communication. For example, the routing 
of a file that requires multiple packets to be sent in order to transmit the 
entire file across the network, which requires the receiving end to properly 
protocol process the packets that make up the file and re-assemble the data 
portions in order for communication of the file to properly occur. 

Applicants note that claim 42 has been amended to recite an "apparatus for 
transferring a packet to a host computer system from a network interface for the host 
computer system." As noted above, the "network bridge/router" of Flanders is directed 
to forwarding frames "for receipt by a downstream network device," rather than 
"transferring a packet to a host computer system from a network interface for the host 
computer system." For at least this reason, applicants respectfully assert that claim 42 is 
not obvious over Flanders. 

In addition, applicants agree with the Office Action that Flanders does not teach 
"a flow re-assembler configured to re-assemble a data portion of said first packet with a 
data portion of a second packet in said communication flow." Applicants respectfully 
assert, moreover, that it would not have been obvious to modify Flanders "to re-assemble 
a data portion of said first packet with a data portion of a second packet in said 
communication flow." Because the frames of Flanders are forwarded, and because 
networks such as Ethernet networks typically have rules limiting frame sizes, reassembly 
of the data would likely cause the frames to be too large to forward, thwarting the 
primary purpose of Flanders. For at least this additional reason, applicants respectfully 
assert that claim 42 is not obvious over Flanders. 
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Claim 44 has been amended to recite in part "a re-assembler for storing data 
portions of said multiple packets without header portions in a first portion of said 
memory." Support for this amendment can be found, for example, on page 18, lines 13- 
24, page 25, lines 8-1 1 and page 26, lines 16-17. 

Applicants respectfully assert that Flanders does not teach "a re-assembler for 
storing data portions of said multiple packets without header portions in a first portion of 
said memory." Moreover, applicants assert that it would not have been obvious to 
modify Flanders to create "a re-assembler for storing data portions of said multiple 
packets without header portions in a first portion of said memory." Because the frames 
of Flanders are forwarded, and because networks such as Ethernet networks typically 
have rules limiting frame sizes, "storing data portions of said multiple packets without 
header portions" would likely cause the frames to be too large to forward, thwarting the 
primary purpose of Flanders, as well as delaying any forwarding that actually occurred, 
without any discernable benefit. For at least this reason, applicants respectfully assert 
that amended claim 44 is not obvious over Flanders. 



T. Claim 47 

Regarding claim 47, the Office Action states: 

Regarding claim 47, Flanders disclosed a device for receiving a 
packet from a network and transferring the packet to a host computer 
system, comprising: 

a parser configured to parse a header portion of a packet received 
from a network, wherein said parsing comprises: determining whether a 
header within said header portion conforms to one of a set of 
communication protocols (Flanders, col. 3, lines 60-65, "RHP (Receive 
Header Processor) determines the protocol being used for the received 
data unit"; See also col. 6, lines 50-51); and 

if said header conforms to one of said communication protocols, 
extracting information from said header portion to identify a 
communication flow to which said packet belongs (Flanders, col. 6, line 
50 through col. 7, line 5, port information extracted from the received 
frame in order to classify packet according to flow ID, the information 
extracted from the packet used as a flow key to look the packet up); a flow 
memory configured to store a flow identifier for identifying said 
communication flow; a flow manager configured to assign an operation 
code to said packet, wherein said operation code: indicates a status of said 
packet; and indicates a manner of transferring said packet to the host 
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computer system; a packet memory configured to store said packet 
(Flanders, col. 6, line 65 through col. 7, line 15, in accordance with the 
received frame, a status word is set; see also, col. 4, lines 15-23. Flanders 
further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the 
disclosed device system for processing in accordance with said pre- 
selected protocol. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the information from that packet. For example, using the very 
well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol 
process the TCP/IP packets, which are clearly routed through the Internet, 
via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination performing the proper 
protocol processing in order to obtain the predictable result of the 
destination device being able to successfully interpret that packet at the 
receiving end, thereby resulting in successful communication. 



Claim 47 has been amended to recite in part "a transfer module configured to 
transfer said packet from said packet memory to the host computer system in accordance 
with said operation code, wherein said device is coupled to the host computer system by a 
bus." Support for this amendment can be found, for example, on page 4, line 31 to page 
5, line 7. Applicants respectfully assert that Flanders does not teach "a transfer module 
configured to transfer said packet from said packet memory to the host computer system 
in accordance with said operation code, wherein said device is coupled to the host 
computer system by a bus." Instead, Flanders states in column 9, lines 41-43: "Outbound 
frames are forwarded from the TXSM FIFO 64 over the respective output port 20 of the 
network interface module 14 for receipt by a downstream network device." For at least 
this reason, applicants respectfully assert that claim 47 and all the claims that depend 
from claim 47 are not obvious over Flanders. 
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U. Claim 18 



Claim 18 stands rejected under 35 U.S.C. 103(a) as allegedly being unpatentable 
over Flanders in view of U.S. Patent No. 5,991,265 to Lincoln. Regarding claim 18, the 
Office Action states: 

Regarding claim 18, Flanders disclosed the limitations as described 
in claim 1, including processing of the header at a Receive Header 
Processor (Flanders, col. 1, lines 50-60). 

Flanders did not explicitly state storing the data portion in a re- 
assembly storage area and one or more headers in a header storage area. 

In an analogous art of packet processing, Lincoln disclosed packet 
processing in which the system transfers the cell payloads to a reassembly 
memory while processing the headers from control memory and then 
combining the header and payload before transferring the cell (Lincoln, 
col. 5, lines 30-40). As such, Lincoln provides evidence that it is well 
known to divide packets between header and payload in order to perform 
header processing of the packets. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to utilize the splitting of packet 
header and payload as performed in the teachings of Lincoln in order to 
provide the system of Flanders in order to reduce the amount of data to be 
analyzed by the RHP in order to process the headers in a more efficient 
manner. 

As noted above, claim 1, from which claim 18 depends, has been amended so that 
it is nonobvious over the "network bridge/router" of Flanders. The asynchronous transfer 
mode (ATM) system and method of Lincoln is also directed to forwarding packets rather 
than terminating TCP, but as its name implies, provides such forwarding in a single 
direction at a time, as opposed to the bidirectional communication of TCP. Thus, 
applicants respectfully submit that Lincoln does not render claim 1 8 or claim 1 
unpatentable. 

Claims 32, 45 and 54 stand rejected under 35 U.S.C. 103(a) as allegedly being 
unpatentable over Flanders in view of U.S. Patent No. 5,590,328 to Seno et al. ("Seno"). 

V. Claim 32 

Regarding claim 32, the Office Action states: 
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Regarding claim 32, Flanders disclosed a method of transferring a 
packet received at a network interface to a host computer system, 
comprising: 

receiving a packet from a network, storing said packet in a packet 
memory and parsing a header portion of said packet; extracting a value 
stored in said header portion; identifying a communication flow 
comprising said packet (Flanders, col. 3, lines 60-65, "RFfP (Receive 
Header Processor) determines the protocol being used for the received 
data unit"; See also col. 6, lines 50-51; col. 6, line 50 through col. 7, line 5, 
port information extracted from the received frame in order to classify 
packet according to flow ID, the information extracted from the packet 
used as a flow key to look the packet up); 

determining whether a header in said header portion conforms to a 
pre-selected protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header 
Processor) determines the protocol being used for the received data unit"); 

determining whether a second packet in said packet memory is part 
of said communication flow (Flanders, col. 1, lines 39-40, Flanders 
disclosed performing the same for multiple received data units); and 

Flanders further disclosed forwarding the packets for receipt by a 
downstream network device (Flanders, col. 9, lines 40-43) 

Flanders did not explicitly state the step of storing said packet in a 
host memory area in the downstream network device. 

However, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made that since the router of Flanders 
clearly routes the packet to a network device, that the network device must 
perform the proper protocol processing on the packet in order to properly 
interpret the information from that packet, thereby requiring storing of the 
packet. For example, using the very well known TCP/IP protocol, in order 
for two computers to successfully communicate via TCP/IP (Flanders, Fig. 
6), both computers must protocol process the TCP/IP packets, which are 
clearly routed through the Internet, via routers such as the one described 
by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to interpret the routing of a 
packet to its destination to include that destination actually storing the 
packet in order to perform the proper protocol processing in order to 
obtain the predictable result of the destination device being able to 
successfully interpret that packet at the receiving end, thereby resulting in 
successful communication. 

Flanders also did not explicitly state wherein, if the host computer 
system contains a plurality of processors, identifying a processor to 
process said packet; 

In an analogous art, Seno disclosed a protocol parallel processing 
device in which the device determines which processor, among which of 
multiple processors, to process the packet (Seno, col. 2, lines 35-65). 
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One of ordinary skill in the art would have been motivated to 
combine the teachings of Flanders and Seno since both teachings involve 
protocol processing of packets, and as such, both are within the same 
environment. 

Therefore it would have been obvious to one of ordinary skill in 
the art to incorporate the "multiple processors" teaching as disclosed by 
Seno into the teachings of Flanders in order to distribute communications 
across multiple processors, thereby improving efficiency of routing data 
through the router as the load is distributed among multiple processors, 
while also increasing throughput (Seno, col. 2, lines 15-35). 

Claim 32 has been amended to recite "if the host computer system contains a 
plurality of processors such that a first of the processors is on the network interface and a 
second of the processors is on the host computer, identifying a processor of the first and 
second processors to process said packet." Applicants respectfully assert that neither 
Seno nor Flanders teaches or suggests this recitation, and that claim 32 is nonobvious 
over Flanders in view of Seno. 



W. Claim 45 

Regarding claim 45, the Office Action states: 

Regarding claim 45, Flanders disclosed the limitations as described 
in claim 42. 

Flanders also did not explicitly state wherein, comprising: a load 
distributor for identifying a first processor within the host computer 
system for processing said first packet and said second packet; wherein 
said load distributor identifies a second processor in the host computer 
system for processing a packet from a different communication flow. 

In an analogous art, Seno disclosed a protocol parallel processing 
device in which the device determines which processor, among which of 
multiple processors, to process the packet according to the communication 
(Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to 
combine the teachings of Flanders and Seno since both teachings involve 
protocol processing of packets, and as such, both are within the same 
environment. 

Therefore it would have been obvious to one of ordinary skill in 
the art to incorporate the "multiple processors" teaching as disclosed by 
Seno into the teachings of Flanders in order to distribute communications 
across multiple processors, thereby improving efficiency of routing data 
through the router as the load is distributed among multiple processors, 
while also increasing throughput (Seno, col. 2, lines 15-35). 
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As noted above, claim 42, from which claim 45 depends, has been amended to be 
patentable over Flanders. Thus, applicants respectfully disagree with the Office Action 
statement that ". . .Flanders disclosed the limitations as described in claim 42." Moreover, 
claim 45 has been amended to recite "wherein said first processor is a part of said 
communication device and said second processor is a part of a host computer that is 
connected to said communication device." Applicants respectfully assert that neither 
Seno nor Flanders teaches or suggests this recitation, and that claim 45 is nonobvious 
over Flanders in view of Seno. 



X. Claim 54 

Regarding claim 54, the Office Action states: 

Regarding claim 54, Flanders disclosed the limitations as described 
in claim 47. Flanders also did not explicitly state wherein said host 
computer system is a multi-processor host computer system, further 
comprising a load distributor configured to select one of said multiple 
processors for processing said packet in accordance with one of said 
communication protocols. 

In an analogous art, Seno disclosed a protocol parallel processing 
device in which the device determines which processor, among which of 
multiple processors, to process the packet according a protocol (Seno, col. 
2, lines 35-65). 

One of ordinary skill in the art would have been motivated to 
combine the teachings of Flanders and Seno since both teachings involve 
protocol processing of packets, and as such, both are wthin the same 
environment. 

Therefore it would have been obvious to one of ordinary skill in 
the art to incorporate the "multiple processors" teaching as disclosed by 
Seno into the teachings of Flanders in order to distribute communications 
across multiple processors, thereby improving efficiency of routing data 
through the router as the load is distributed among multiple processors, 
while also increasing throughput (Seno, col. 2, lines 15-35). 

As noted above, claim 47, from which claim 54 depends, has been amended to be 
patentable over Flanders. Thus, applicants respectfully disagree with the Office Action 
statement that ". . .Flanders disclosed the limitations as described in claim 47." Moreover, 
claim 54 has been amended to recite "wherein said first processor is a part of said 
communication device and said second processor is a part of a host computer that is 
connected to said communication device." Applicants respectfully assert that neither 
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Seno nor Flanders teaches or suggests this recitation, and that claim 45 is nonobvious 
over Flanders in view of Seno. 



VII. Double Patenting 

Claims 1 and 24 stand provisionally rejected on the ground of nonstatutory 

obviousness-type double patenting as allegedly being unpatentable over claim 3 1 of 

copending Application No. 10/634,062. In this regard, the Office Action states: 

Although the conflicting claims are not identical, they are not 
patentably distinct from each other because claim 31 of patent application 
10/634,062 contain(s) every element of claim 1 of the instant application 
and as such anticipate(s) claims 1, 24 of the instant application. "A later 
patent claim is not patentably distinct from an earlier patent claim if the 
later claim is obvious over, or anticipated by, the earlier claim. In re 
Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of 
obviousness-type double patenting because the claims at issue were 
obvious over claims in four prior art patents); In re Berg, 140 F.3d at 
1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of 
obviousness-type double patenting where a patent application claim to a 
genus is anticipated by a patent claim to a species within that genus). " 
ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United 
States Court of Appeals for the Federal Circuit, ON PETITION FOR 
REHEARING EN BANC (DECIDED: May 30, 2001). This is a 
provisional obviousness type double patenting rejection because the 
conflicting claims have not in fact been patented. 

Accompanying this response is a Terminal Disclaimer over copending 
Application No. 10/634,062, to obviate this provisional rejection. 



VIII. Allowable Subject Matter 

The Office Action states that Claims 33-40, 58-62 are allowed, and that claims 19, 
41, 57 are objected to as being dependent upon a rejected base claim, but would be 
allowable if rewritten in independent form including all of the limitations of the base 
claim and any intervening claims. 

Applicants appreciate the Examiners indication of patentable subject matter. As 
discussed above, however, applicants respectfully assert that all of the pending claims are 
patentable, in light of the amendments to the claims. 
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IX. Conclusion 

Applicants appreciate the time spent by the Examiner for his thorough 
examination of this large set of claims as well as his review of this reply. Applicants 
believe that the claims are now allowable and solicit a Notice of Allowance. Should the 
Examiner have any questions about this reply or application he is respectfully requested 
to telephone the undersigned. 



Respectfully submitted, 

/Mark Lauer/ 
Mark Lauer 
Reg. No. 36,578 
Silicon Edge Law Group LLP 
6601 Koll Center Parkway 
Suite 245 

Pleasanton, CA 94566 
Tel: (925) 621-2121 
Fax: (925) 621-2125 
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